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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document is part of a TS-family covering the 3 rd Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

32.371: "Security Management concept and requirements". 

32.372: "Security services for Integration Reference Points (IRP); Information Service (IS)". 

32.373: "Security services for Integration Reference Points (IRP); Common Object Request Broker 

Architecture (CORBA) solution". 

32.375 "Security services for Integration Reference Points (IRP); File integrity solution". 

In 3GPP SA5 context, IRPs are introduced to address process interfaces at the Itf-N interface. The Itf-N interface is 
built up by a number of Integration Reference Points (IRPs) and a related Name Convention, which realize the 
functional capabilities over this interface. The basic structure of the IRPs is defined in 3GPP TS 32.101 [1] and 
3GPP TS 32.102 [2]. IRP consists of IRPManager and IRP Agent. Usually there are three types of transaction between 
IRPManager and IRP Agent, which are operation invocation, notification, and file transfer. 

However, there are different types of intentional threats against the transaction between IRPManagers and IRP Agents. 
All the threats are potential risks of damage or degradation of telecommunication services, which operators should take 
measures to reduce or eliminate to secure the telecommunication service, network, and data. 

By introducing Security Management, the present document describes security requirements to relieve the threats 
between IRPManagers and IRP Agents. 

As described in 3GPP TS 32.101 [1], the architecture of Security Management is divided into two layers: 

Layer A - Application Layer 

Layer B - OAM&P transport network 

The threats and Security Management requirements of different layers are different, which should be taken into account 
respectively. 
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3GPP defines three types of IRP specifications, (see 3GPP TS 32.102 [2]). One type relates to the definitions of the 
interface deployed across the Itf-N. These definitions need to be agreed between the IRPManagers and IRP Agents so 
that meaningful communication can occur between them. An example of this type is the Alarm IRP. 

The other two types (NRM IRP and Data Definition IRP) relate to the network resource model (schema) of the managed 
network. This network schema needs to be agreed between the IRPManagers and IRP Agents so that network 
management services can be provided to the IRPManager(s) by the IRPAgent(s). An example of this type is the 
UTRAN NRM IRP. 

This Requirement specification is applicable to the Interface IRP specifications. That is to say, it is concerned only with 
the security aspects of operations/notifications/file deployed across the Itf-N. 
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1 Scope 



The present document defines, in addition to the requirements defined in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2], 
the requirements for Security Management IRP. 

The purpose of the present document is to specify the necessary security features, services and functions to protect the 
network management data, including Requests, Responses, Notifications and Files, exchanged across the Itf-N. 

Telecommunication network security can be breached by weaknesses in operational procedures, physical installations, 
communication links, computational processes and data storage. Of concern here in the present document is the security 
problems resulting from the weaknesses inherent in the communication technologies (i.e., the 3GPP-defined Interface 
IRPs and their supporting protocol stacks) deployed across the Itf-N. 

Appropriate level of security for a telecommunication network is essential. Secured access to the network management 
applications, and network management data, is essential. The 3GPP-defined Interface IRPs (and their supporting 
protocol stacks), deployed across the Itf-N, are used for such access, and therefore, their security is considered essential. 

Many network management security standards exist. However, there is no recommendation on how to apply them in the 
Itf-N context. Their deployment across the Itf-N is left to operators. The present document and the corresponding 
solutions identify and recommend security standards in the Itf-N context. 

The business case for secured Itf-N is complex as it does not relate to the functions of the Interface IRPs (the functions 
are constant) but rather, it relates to variants such as the cost of recovering from security breaks, the probability of 
security incidents and the cost of implementing Security Management, all of which differs depending on specific 
deployment scenarios. 

The present document describes the security functions for a 3G network in terms of Security Domains (subclause 4.1). 
Clause 5 defines the Itf-N Security Management scope in terms of its context (subclause 5.1) and the possible threats 
that can occur there are defined in clause 6. Clause 7 specifies the Itf-N security Requirements. 



References 



The following documents contain provisions that, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] ITU-T Recommendation M.3016 (1998): "TMN security overview". 

[4] 3GPP TS 33.102: "3G Security; Security architecture". 

[5] ITU-T Recommendation X.800: "Security architecture for Open Systems Interconnection for 

CCITT applications". 

[6] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in ITU-T Recommendation X.800 [5], ITU-T 
Recommendation M.3016 [3] and the following apply: 

access control: prevention of unauthorized use of a resource, including the prevention of use of a resource in an 
unauthorized manner, see ITU-T Recommendation X.800 [5]. 

accountability: property that ensures that the actions of an entity may be traced uniquely to the entity, see ITU-T 
Recommendation X.800 [5]. 

audit: See Security Audit. 

authentication: See data origin authentication and peer element authentication, see ITU-T Recommendation X.800 [5]. 

authorization: granting of rights, which includes the granting of access based on access rights, see ITU-T. 
Recommendation X.800 [5] 

availability: property of being accessible and useable upon demand by an authorized entity, see ITU-T. 
Recommendation X.800 [5] 

confidentiality: property that information is not made available or disclosed to unauthorized individuals, entities, or 
processes, see ITU-T Recommendation X.800 [5]. 

credentials: data that is transferred to establish the claimed identity of an entity, see ITU-T Recommendation X.800 
[5]. 

cryptography: discipline which embodies principles, means, and methods for the transformation of data in order to 
hide its information content, prevent its undetected modification and/or prevent its unauthorized us, see ITU-T 
Recommendation X.800 [5]. 

data integrity: property that data has not been altered or destroyed in an unauthorized manner, see ITU-T 
Recommendation X.800 [5]. 

data origin authentication: corroboration that the source of data received is as claimed, see ITU-T Recommendation 
X.800 [5]. 

denial of service: prevention of authorized access to resources or the delaying of time-critical operations, see ITU-T 
Recommendation X.800 [5]. 

digital signature: data appended to, or a cryptographic transformation (see cryptography) of a data unit that allows a 
recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the 
recipient, see ITU-T Recommendation X.800 [5]. 

eavesdropping: breach of confidentiality by monitoring communication, see ITU-T Recommendation M.3016 [3]. 

forgery: entity fabricates information and claims that such information was received from another entity or sent to 
another entity, see ITU-T Recommendation M.3016 [3]. 

Integration Reference Point (IRP): See 3GPP TS 32.150 [6]. 

IRPAgent: See 3GPP TS 32.150 [6]. 

IRPManager: See 3GPP TS 32.150 [6]. 

loss or corruption of information: integrity of data transferred is compromised by unauthorized deletion, insertion, 
modification, re-ordering, replay or delay, see ITU-T Recommendation M.3016 [3]. 

Operations System (OS): indicates a generic management system, independent of its location level within the 
management hierarchy. 

masquerade: pretence by an entity to be a different entity, see ITU-T Recommendation X.800 [5]. 
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password: confidential authentication information, usually composed of a string of characters, see ITU-T 
Recommendation X. 800 [5]. 

Peer Entity Authentication: The corroboration that a peer entity in an association is the one claimed, see ITU-T 
Recommendation X.800 [5]. 

repudiation: denial by one of the entities involved in a communication of having participated in all or part of the 
communication, see ITU-T Recommendation X.800 [5]. 

security audit: independent review and examination of system records and activities in order to test for adequacy of 
system controls, to ensure compliance with established policy and operational procedures, to detect breaches in security, 
and to recommend any indicated changes in control, policy and procedures, see ITU-T Recommendation X.800 [5]. 

threat: potential violation of security, see ITU-T Recommendation X.800 [5]. 

unauthorized access: entity attempts to access data in violation of the security policy in force, see ITU-T 
Recommendation M. 30 16 [3]. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CM Configuration Management 

CS Communication Surveillance 

DCN Data Communication Network 

EM Element Manager 

EP Entry Point 

FT File Transfer 

IRP Integration Reference Point 

IS Information Service (see 3GPP TS 32. 101 [1]) 

ITU-T International Telecommunication Union - Telecommunication standardization sector 

NE Network Element 

NL Notification Log 

NM Network Manager 

NRM Network Resource Model 

OAM&P Operations, Administration, Maintenance and Provisioning 

OS Operations System 

PM Performance Management 

TM Test Management 

TMN Telecom Management Network 

UML Unified Modelling Language (OMG) 

UMTS Universal Mobile Telecommunications System 
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Security Management background 



The objective of this clause is to provide the foundations for the development of security within the management 
domain and scope of a third generation mobile telecommunications network. This will be accomplished through the 
establishment of the boundaries of security from the perspective of the management subsystem of a 3G mobile 
telecommunications network. The definition of the concepts of security objectives, security threats, and finally security 
mechanisms and services are identified. 

This clause gives an overall view of Security Management in general, before entering clause 5 Security Management 
context and architecture discussion. The general security mechanisms and services used by the management subsystem 
will depend on the requirements defined in clause 7. How they are used is out side the scope of these requirements. 
Such aspects may be further specified in corresponding IS specifications. 



4.1 Security domains 



Security within a telecommunications network is a vast functional area covering most aspects and all components of a 
3G system. To devise a solution more manageable and easier to evolve, the total network security scope is split into 
different and separate parts. For the present document purpose, the security scope is partitioned into four different 
domains. 



Security Management Domain 






Figure 1 : Security model/architecture 

The User domain contains a set of security features that protects User Equipment against attacks on radio interface and 
provides users with secure access to subscribed services and applications. Examples of security features in this user 
domain are: 



• 



• 



The set of security features that provide users with secure access to 3G services, and which in particular protect 
against attacks on the (radio) access link; 

The set of security features that secure access to mobile stations; 

The set of security features that enable applications in the user and in the provider domain to securely exchange 
messages. 



The Network domain provides the set of security features that enable nodes in the provider domain to securely 
exchange signalling data, and protect against attacks on the wireline network. This domain covers protection of the 
network, network elements and all internal (control and signalling) traffic against security threats. The network 
elements can belong to a single operator (intra-operator) or to different operators (inter-operator). 

The OAM&P domain accommodates management tools to supervise all nodes of a cellular network. The OAM &P 
domain security provides the protection of all the operation and maintenance traffic, authentication of users, 
applications and access control to the nodes. It protects the resources of network elements and management applications 
from intentional and unintentional destructive manipulation. 
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The Security Management domain comprises all activities to establish, maintain and terminate the security aspects of 
a system. Examples of the features covered by the Security Management domain are: 

• Management of security services; 

• Installation of security mechanisms; 

• Key management (management part); 

• Establishment of identities, keys, access control information, etc.; 

• Management of security audit trail and security alarms. 

Using the above partitioned view, the scope of the present document is focused on security requirements of the 
OAM &P domain and is not focused on requirements of other domains. Furthermore, since the Itf-N operates within the 
OAM &P domain, the scope of the present document is further "narrowed" towards a component, namely the Itf-N 
component of the OAM&P domain. 

For further explanation of the semantics of the general security terms referred to in following subclauses 4.2, 4.3 and 
4.4, refer to ITU-T Recommendation X.800 [5]. It is not intended to repeat them here. 



4.2 Security objectives 



Security objectives are necessary in order to define the intended purpose of security within a network. ITU-T 
Recommendation M.3016 [3] defines the following objectives for security. 

• Confidentiality; 

• Data integrity; 

• Accountability; 

• Availability; 



4.3 Security threats 



A security threat is defined by ITU-T Recommendation M.3016 [3] as a potential violation of security that can be 
directed at one of the four basic security objectives (see subclause 4.2). ITU-T Recommendation X.800 [5] defines the 
following security threats: 

• Masquerade. 

• Eavesdropping. 

• Unauthorized access. 

• Loss or corruption of information. 

• Repudiation. 

• Forgery. 

• Denial of service. 

NOTE: In contemporary network security jargon, "denial of service" is most often used to describe a class of 
attacks that are intended to subvert the delivery of service. In this context the "denial of service" threat 
can be best described as "denial of service delivery". 
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4.4 Security Mechanisms and services 

ITU-T Recommendation X.800 [5] defines a set of security mechanisms that can be used to implement security 
objectives within a network Security mechanisms are manifested within and/or by security services. The fundamental 
security services are identified by ITU-T Recommendation X.800 [5] as being: 

Peer entity authentication. 

Data origin authentication. 

Access control service. 

Connection confidentiality. 

Connectionless confidentiality. 

Selective field confidentiality. 

Traffic flow confidentiality. 

Connection Integrity with recovery. 

Connection integrity without recovery. 

Selective field connection integrity. 

Connectionless integrity. 

Selective field connectionless integrity. 

Non-repudiation Origin. 

Non-repudiation. Delivery. 



4.5 TMN perspective regarding security threats 

Table 1 is taken from ITU-T Recommendation M.3016 [3]. It shows TMN perspective on which security functions are 
required to counter the Security Threats identified in subclause 4.3. 

The security mechanisms identified in subclause 4.4 may be used to achieve the security requirements. 

Table 1 : Correlation of security management functional area with threats 
(from ITU-T Recommendation M.3016 [3]) 



Functional Requirement Area 


C/> 

CD 
O 

C 

a) 

3 
fi) 
(Q 
CD 

3 

CD 

3 

l-H 


fi) 

(/> 

c 

CD 

fi) 

Q. 
CD 


m 

< 

CD 
(/> 

Q. 

O 

■o 
■o 

5' 


si 

2 =" 

CD o 

(/> „ 

(D 

Q. 


1- 
o o 

5 W 

i 

i'l" 


J3 

CD 

c 

Q. 

2." 
5" 

3 


■n 
o 

CD 


D 

<D 

3 

§! 

o 

(D 
CD 


Verification of identities 


X 




X 










Controlled access and authorization 






X 








X 


Protection of confidentiality 




X 


X 










Protection of data integrity 








X 








Accountability 
















Activity logging 


X 




X 




X 


X 


X 


Alarm reporting 


X 




X 


X 






X 


Audit 


X 




X 




X 


X 


X 



ETSI 



3GPP TS 32.371 version 8.0.0 Release 8 



12 



ETSI TS 132 371 V8.0.0 (2009-01) 



5 Security Management context and architecture 

This clause puts the security issues identified in clause 4 into the context of 3G OAM&P domain. It also identifies the 
architectural framework within which security is required in 3G OAM&P domain. 



5.1 



Context 



This subclause defines the Itf-N Security Management (SM) Context. The Itf-N is one of many interfaces defined 
within the OAM&P domain (see subclause 4.1). Therefore, this Itf-N Security Management Context is within that 
OAM&P Domain. 

The following diagram highlights the types of communication links that are realized across the Itf-N. 
All 3GPP Interface IRPs operate across the Itf-N using these links. 

The link-a-1 and link-a-2 represent the two-way links carrying Request from NM (playing the role of IRPManager) and 
Response from Managed System (playing the role of IRP Agent). The link-b represents a one-way link carrying 
Notification from the Managed System (playing the role of IRP Agent). The link-c represents the two-way link for File 
download and upload. 





link-a-1 



link-a-2 
link-b 



Itf-N 




FileTransfer IRP 



Managed 
System 



NotificationIRP 



Notification distribution 
Service 



Figure 2: Security management context 

The Requirements are related to these communication links. They are also related to the end-points (communicating 
entities) of the communication links. These end-points are the NM when playing the role of IRPManager and the 
Managed System when playing the role of IRP Agent. 

Securing the end-points means to protect them from unauthorized use (see subclause 4.3). 

The Requirements are not related to other kinds of links nor entities that exist in the OAM&P Domain. Examples of link 
and entity types to be excluded are: 

• Non-IRP links reaching NM (e.g. the customer-service-oriented application accessing the applications in NM 
space, a user to logon to NM). 

• Non-IRP links reaching IRP Agents (e.g. a user to log on to an Element Manager, a remote network management 
application accessing the IRP Agent functions). 

• Non-IRP links reaching Network Elements (e.g. a subnetwork management application communicating with the 
MSC using vendor- specific means, a user to logon to a radio base station). 

• All applications running in the NM space and Managed System space that are not playing the roles of 
IRPManager and IRP Agent. 
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5.2 



Architecture 



The security architecture for 3G networks is defined within 3GPP TS 33.102 [4] based on the concept of stratums and 
feature groups. The present document extends the security architecture defined within 3GPP TS 33.102 [4] to support 
security in the management system of a 3G network. The following figure depicts the extension of the 3G security 
architecture to cover 3G OAM&P Security. 




Itf-N 




Server/NEs 

ZZZL 



OAM&P Transport network 



Layer 
A 

B 



Figure 3: The Management layers of the 3G security architecture 
(based on 3GPP TS 32.101 [1]) 

Within the Management layer there is defined an additional security feature group. This feature group is: 

OAM&P Domain Security (Vl-for further study): the set of security features that provides protection to all OAM&P 
communication related to all applications, actors, and communications traffic related to the operations and management 
of a 3G network over Itf-N. 



6 Security threats in IRP context 

6.1 Security threats to IRPs 

The table below identifies the security threats in IRP context for the present release. 
The definitions of the column headings of the table follow: 

1) Manager Masquerade: One entity can masquerade as an IRPManager. 

2) Unauthorized Access: Unauthorized access by an IRPManager to IRP Agent, causing unexpected disclosure of 
information from IRP Agent, and even damage to IRP Agent and Network Elements under its control. 

3) Agent Masquerade: One entity can masquerade as an IRP Agent. 

4) Loss or Corruption: Loss or corruption of information including bulk data. 

5) Eavesdropping (Note 3): Eavesdropping on sensitive management information. 

6) Repudiation: IRPManager and/or IRP Agent denies the fact that it has sent or received some management 
information. 

"File transfer" in the row headings of the table refers to the file transfer mechanism used by the corresponding IRPs. 
Because the IRPs use the file transfer mechanisms provided by the File Transfer IRP the threats relating to file transfer 
mechanisms are shown in rows associated with the FT IRP. 

"File content" in the row headings of the table refers to the file content of files used by the corresponding IRPs. The 
threats to file content are dependant on the IRP to which the file belongs, and these are therefore shown against the IRP 
that created or uses the files. 



ETSI 



3GPP TS 32.371 version 8.0.0 Release 8 



14 



ETSI TS 132 371 V8.0.0 (2009-01) 



Table 2: Matrix of security threats 
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H 


file content (Passive) 


N/A 


N/A 


L 


L 


L 


L 


Alarm IRP 














operation 


H 


L 


L 


N/A 


L 


H 


notification 


N/A 


N/A 


L 


L 


L 


L 


file content 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


Notification IRP 
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H 


H (note 2) 
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L 


H 


notification (n/a) 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


TMIRP 














operation 


H 


H (note 2) 


L 


N/A 


L 


H 


notification 


N/A 


N/A 


L 


L 


L 


L 


file content 


N/A 


N/A 


L 


L 


L 


L 


FT IRP 














operation 


H 


H 


L 


N/A j 


L 


H 


notification 


N/A 


N/A 


L 


L 


L 


L 


file transfer 


H 


H 


N/A 


N/A 


L 


H 


EPIRP 














operation 


H 


H 


L 


N/A 


L 


H 


notification 


N/A 


N/A 


L 


L 


L 


L 


PMIRP 














operation 


H 


L(Note 2) 


L 


N/A 


L 


H 


notification 


N/A 


N/A 


L 


L 


L 


L 


file content 


N/A 


N/A 


N/A 


L 


L 


L 


CSIRP 














operation 


H 


L 


L 


N/A 


L 


H 


notification 


N/A 


N/A 


L 


L 


L 


L 


NLIRP 














operation 


H 


L 


L 


N/A 


L 


H 


notification 


N/A 


N/A 


L 


L 


L 


L 


file content 


N/A 


N/A 


N/A 


L 


L 


L 


Legend: 

H: A security threat of a higher level. 
L: A security threat of a lower level. 
N/A: Not applicable. 
TBD: To Be Decided. 


NOTE 1 : The IRPAgent shall check that a downloaded file has not been changed during a session before 

performing a pre-activation or activation. 
NOTE 2: Relationship between operations is for further study. 

NOTE 3: Assume security of DCN between IRPManager and IRPAgent is not described in the present document. 
NOTE 4: Applicable when Kernel CM IRP is used in isolation. 
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6.2 Mapping of Security requirements and Threats in IRP 
Context 

It is necessary to take measures to prevent the threats described in subclause 6.1 in IRP context. 
Table 3 shows how the threats identified in subclause 6.1 are countered by security mechanisms. 

Table 3: Mapping of security requirements and threats 
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Manager Authentication 


X 


X 










Agent Authentication 






X 








Authorization 




X 










Integrity protection 








X 






Confidentiality protection 




X 






X 




Non-repudiation 












X 


Security alarm 


X 


X 




X 






Activity log 


X 


X 








X 

(see note) 


NOTE: Activity Log can partly counter the threat of Repudiation. 
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7 Security requirement of Itf-N 

Table 4 identifies the security requirements in IRP context for the present release. 
The definitions of the column headings of the table follow: 

1) Manager Authentication: IRP Agent authenticates IRPManager. It implies that the IRPManager shall be 
identified so as to be authenticated. 

2) Authorization: IRP Agent authorizes the IRPManager, i.e. IRP Agent checks if the IRPManager has been 
authorized to perform the operations on receiving operation request. 

3) Agent Authentication: IRPManager authenticates IRP Agent. It implies that the IRP Agent shall be identified so 
as to be authenticated. 

4) Integrity Protection: Receiver (IRPManager or IRP Agent) of bulk data checks the integrity of the bulk data. 

5) Confidentiality Protection: The confidentiality of sensitive management information is protected. 

6) Non-Repudiation: Means are provided to prove that exchange of data between IRP Agent and IRPManager 
actually took place. 

7) Security Alarm: IRP Agent issues security alarm to IRPManager when breach of security is detected, e.g. request 
for unauthorized operation, damage of file transferred, etc. 

8) Activity Log: It helps to find out who (i.e. identities of IRPManager) did what (i.e. names of operations and 
notifications) and when. This capability is called the activity log. It includes information like requested 
operations, operations performed, emitted notifications/alarms, and transferred files. In the context of Itf-N, 
IRP Agent maintains activity log(s) and the activity log(s) of IRPManager are out of scope of the present 
document. 

"File transfer" in row headings of the table refers to the file transfer mechanism used by corresponding IRP. Because the 
IRPs use the file transfer mechanisms provided by the File Transfer IRP the threats relating to file transfer mechanisms 
are shown in rows associated with the FT IRP. 

"File content" in row headings of the table refers to the file content of file created or used by the corresponding IRP. 

"Active" in relation to file content for Bulk CM IRP refers to configuration files downloaded to the IRP Agent from the 
IRPManager. 

"Passive" in relation to file content for Bulk CM IRP refers to configuration files uploaded to the IRPManager from the 
IRPAgent. 
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Table 4 Matrix of security requirements 
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Basic CM IRP 


















operation 


X 


X 


- 


N/A 


- 


- 


X 


X 


notification 


N/A 


N/A 


- 


- 


- 


- 


N/A 


- 


Kernel CM IRP 


















operation 


X 


X 


- 


N/A 


- 


- 


X 


X 


Notification (note 6) 


N/A 


N/A 


- 


- 


- 


- 


N/A 


- 


Bulk CM IRP 


















operation 


X 


X 


- 


N/A 


- 


- 


X 


X 


notification 


N/A 


N/A 


- 


- 


- 


- 


N/A 
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file content (Active) 


N/A 


N/A 


N/A 


X 


- 


- 


X 


X (note 3) 


file content 
(Passive) 


N/A 


N/A 


- 


- 


- 


- 


N/A 
(note 2) 
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Alarm IRP 
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- 


file content (note 1) 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


Notification IRP 


















operation 


X 


X (note 5) 


- 


N/A 


- 


- 


X 


X 


notification (n/a) 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 
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X 


X (note 5) 


- 
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- 


- 


X 


X 
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N/A 
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- 


- 
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- 


N/A 


- 
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N/A 


N/A 


- 


- 


- 


- 


N/A 


- 


FT IRP 
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N/A 
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X (note 4) 
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X (note 5) 
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notification 


N/A 


N/A 


- 
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NLIRP 


















operation 


X 


- 


- 


N/A 


- 


- 


X 


X 


notification 


N/A 


N/A 


- 


- 


- 


- 


N/A 


- 


file content 


N/A 


N/A 


- 


- 


- 


- 


N/A 


- 


N/A: Not applicable. 
"-": Not a requirement. 
X: A requirement. 


NOTE 1 : N/A because no file transfer operations for this IRP have yet been defined. 

NOTE 2: This field is N/A because no integrity check is performed on the file contents and therefore no security alarm 

can be issued as a result. If file contents are checked and no requirement for issuing an alarm identified this 

field would be "-". 
NOTE 3: For active files the activity log of Bulk CM IRP contains details of the suboperations. 
NOTE 4: FT IRP is responsible for checking the integrity of the files transferred, but not the file content semantics. 
NOTE 5: Relationship between operations is for further study. 
NOTE 6: Applicable when Kernel CM IRP is used in isolation. 
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Annex A (informative): 

Protocols for IP Network Security to Support Itf-N 

Many security threats exist to the management plane of the telecommunications networks. In addition, new security 
threats to the management plane are being introduced as the network evolves. The purpose of this document is to 
provide security guidelines for using IP Network security protocols such as Internet Protocol Security (IPsec), SSL/TLS 
(Secure Socket Layer/Transport Layer Security) and Secure Shell(SSH) to help mitigate security risks to the 
management network. The security provided by IP Network security protocols may be obtained by implementing these 
protocols within network equipment or through the use of external mechanisms such as IPsec VPN devices. 

In some telecommunications networks, management traffic is transmitted on a separate network from that carrying the 
service provider's end-user traffic. In these networks, security threats to the management plane are isolated from 
malicious activity on the end-user plane. With evolving telecommunications networks however, management traffic is 
often combined on a single network with end-user traffic. Combining traffic in this manner minimizes costs by 
requiring only a single integrated network infrastructure; however, new security challenges are introduced. Threats in 
the end-user plane now become threats to the management plane since the management plane becomes accessible to the 
multitude of end-users. Thus security, which was very important before, becomes even more critical with the evolving 
network. 

Scope 

This document provides recommendations and guidelines for using IP Network security protocols such as Internet 
Protocol Security (IPsec), SSL/TLS (Secure Socket Layer/Transport Layer Security) and Secure Shell (SSH) to help 
mitigate security risks for management traffic. The use of IP Network security protocols can be used to provide a basic 
level of network security for the 3 GPP Itf-N interface and underlying network used to transport management traffic. In 
addition to the use of IP Network security protocols, other aspects of security including operator 

authentication/authorization, operating system hardening and security event logging must also be considered to provide 
an overall secure solution, however these aspects are beyond the scope of this document. 

Framework Model 

The framework model used by this document is from Figure 1, clause 5.1.1 of TS 32.101 [TS 32.101]. This diagram, 
reproduced below in Figure 1, identifies a set of interfaces used by 3GPP. The recommendations of this document 
apply specifically to management interfaces of Type 2 [EM-NM; also known as Interface N], including the underlying 
IP transport network used to support this interface. 

The recommendations and guidelines in this document may also be considered in future to provide security for other 
interfaces such as the Type 1 [NE-EM] interface. 
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Figure A.1 : 3GPP Management System Interactions 



Security Threats 



A number of serious security threats are commonly associated with the OAM&P management network infrastructure. 
Security threats include Masquerade, Eavesdropping, Unauthorized Access, Loss/Corruption of Information, 
Repudiation, Forgery and Denial of Service. 

Attacks may be launched from inside the network by insiders such as disgruntled employees and also from external 
sources such as hackers. IP Network security protocols such as IPsec, SSL/TLS and SSH can be effective in mitigating 
many of these security threats. In addition, other security services may be able to make use of security provided by the 
IP Network security protocols. For example passwords used for application level authentication will be protected 
against eavesdropping when transmitted over a network infrastructure secured by IP Network security protocols. 

Table 1, taken from ITU-T Recommendation M.3016, illustrates a mapping of security functions required to mitigate 
identified security threats [M.3016]. In Table 2, the general capabilities of IP Network security protocols (IPsec, 
SSL/TLS and SSH) is mapped against required security functions. This illustrates how IP Network security protocols 
can help mitigate security vulnerabilities. 
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Table A.1 : Correlation of Security Management Functional Area with Threats 
(from ITU-T Recommendation M.3016 [2]) 



Functional Requirement Area 
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Verification of identities 


X 




X 










Controlled access and authorization 






X 








X 


Protection of confidentiality 




X 


X 










Protection of data integrity 








X 








Activity logging 


X 




X 




X 


X 


X 


Alarm reporting 


X 




X 


X 






X 


Audit 


X 




X 




X 


X 


X 



Table A.2: Correlation of Security Functional Area with Security Services Provided by IP Network 

Security Protocols 



Functional 
Requirement Area 


Threat Mitigation Measures Provided by IP Network Security Protocols. 


Verification of 
identities 


Machine-to-machine (server-to-server) authentication services can be provided based 
on password or X.509 certificates. Application layer authentication is not provided. 


Controlled access 
and authorization 


Network/transport layer packet filtering service can reject non-authorized packets. 


Protection of 
confidentiality 


Confidentiality service is provided by underlying encryption technology within the 
Network Security protocol. The strength of the encryption service can vary to 
extremely strong dependent on underlying encryption algorithm and key length 
chosen. 


Protection of data 
integrity 


Strong data integrity service is provided by underlying cryptographic service within the 
Network Security protocol. (E.g. Keyed Hashed Message Authentication Code with 
Secure Hash Algorithm-1). 


Activity logging 


Not provided. 


Alarm reporting 


Not provided. 


Audit 


Not provided. 



Security Solutions 

Application Layer Security 

Application layer security provides a security solution targeted specifically to a particular application, which must be 
implemented in the end hosts. Application layer security has the advantage of easy access to user credentials because it 
operates in the context of the user, which makes user AAA services easier to implement. Also, an application can be 
extended for security without having to depend on the operating system to provide these services. 
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The disadvantage of application level security is that security mechanisms must be designed independently for every 
application that needs to be secured. Thus, it is very difficult to create seamless and scalable security architectures 
using only application layer security. 

Transport Layer Security 

Transport layer security provides security services at the Transport layer (Layer 4). SSL, which has been revised and 
standardized by the Internet Engineering Task Force (IETF) as TLS, is the security protocol that provides security at the 
transport layer. 

A single SSL/TLS instance can be used to create multiple SSL/TLS sessions through an Internet protocol (IP) network 
to provide security for various applications. Modifications are required to each application to allow that application to 
request SSL/TLS security services. SSL/TLS is the de-facto standard for Web-based HTTP traffic, and all standard 
Web browsers include built-in SSL/TLS technology. 

Because SSL/TLS technology does not operate in the context of the user, obtaining user context is difficult, making it 
harder to implement user AAA services. SSL/TLS is applicable only to TCP traffic and cannot be used to protect UDP 
traffic. 

Network Layer Security 

Network layer security provides security services at the Network layer (Layer 3). The IETF IPsec Suite is the security 
protocol that provides security at the network layer. IPsec is optional for IPv4 and a mandatory component of IPv6. 
IPsec can be used to protect data from any different application or transport protocols. No modifications are required to 
the applications, and the security services appear transparent to the applications. IPsec is the de-facto standard used for 
creating network layer virtual private networks. (IPsec VPN). 

Because IPsec technology does not operate in the context of the user, obtaining user context is difficult, making it 
harder to implement user AAA services. 

Recommendations 

Service providers are increasingly using in-band network management and thus logical separation of management 
traffic through the use of IP network security protocols is a beneficial security practice. Also, security statistics show 
that up to 70% of all compromises of resources are caused by 'insiders'. Use of IP network security protocols for 
management traffic provides a good degree of protection against insiders with the exception of the small group of 
insiders that have legitimate access to the encryption keys. 

It is recommended to provide baseline infrastructure security between machines communicating across the Itf-N 
through the use of IP network security protocols such as IPsec, SSL/TLS and SSH. These IP network security protocols 
employ security services through the use of cryptographic mechanisms and provide services including data 
confidentiality, data integrity, machine-to-machine authentication, and others. The recommended IP network security 
protocols are IPSec (Internet Protocol security suite), Secure Shell (SSH), and Secure Socket Layer/Transport Layer 
Security (SSL/TLS), and the choice and use of a particular IP network security protocol is based on particular service 
provider requirements. 

External IPsec VPN devices may also be used to meet these recommendations for protection of management traffic. 
Using an external IPSec VPN instead of embedded IPsec solutions however introduces extra complexity and does not 
provide end-to-end protection between management servers. Thus the preferred longer-term solution is to incorporate 
the capability directly into the management platforms. 

All of the IP network security protocols rely on underlying cryptographic algorithms such as AES (Advanced 
Encryption Standard), DES (Data Encryption Standard), TDEA (Triple Data Encryption Algorithm), HMAC-MD5 
(Hashed Message Authentication Code with Message Digest 5), HMAC-SHA-1 (Hashed Message Authentication Code 
with Secure Hash Algorithm- 1), RSA (Rivest, Shamir, Adleman) and other cryptographic algorithms to provide the 
security services. Please note that the choice of particular cryptographic algorithms and key lengths for use with IP 
network security protocols is based on particular service provider and market requirements, and no specific 
recommendations are made in this document. {References [FIPS-46-3], [FIPS-197], [RFC 2403], [RFC 2404], [RFC 
2437]}. 
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IPsec Security Services: 

Overview and Capabilities 

IPsec addresses security at the IP layer, provided through the use of a combination of cryptographic and protocol 
security mechanisms. IPSec protocol runs between the Network layer (Layer 3) and the Transport layer (Layer 4) and 
can be used to protect any type of data traffic (TCP or UDP) and is independent of applications. IPsec is designed to 
provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services 
offered by IPsec includes: 

a) Data integrity 

b) Data origin authentication based on IP address 

c) Machine-to-machine authentication 

d) Anti-Replay Protection 

e) Data confidentiality 

f) Cryptographic key exchange 

These objectives are met through the use of two traffic security services, the Authentication Header (AH) and the 
Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and 
protocols. AH service provides data origin authentication, machine-to-machine authentication and data integrity for IP 
packets. ESP service provides data confidentiality service in addition to data origin authentication, machine-to-machine 
authentication and data integrity for IP packets. IPsec mechanisms also designed to be cryptographic algorithm- 
independent to permits selection of different sets of algorithms without affecting the other parts of the implementation. 

Key Management is provided by the Internet Key Exchange (IKE) protocol. Both manual and automatic mechanisms 
for key negotiation between endpoints are provided. Automatic key negotiation can be based on pre-shared keys (e.g. 
passwords) or X.509 certificates. 

Recommendations for use of IPsec for Itf-N Security 

This section provides basic recommendation for the use of IPsec for protection of network management traffic crossing 
the Itf-N interface, and is not intended to be exhaustive. 

a) The Itf-N servers operate in a client-server (host to host) environment and therefore the use IPsec transport 
mode versus IPsec tunnel mode is recommended. 

b) ESP service is recommended versus AH service since it can provide encryption service and/or 
authentication services. AH service can only provide authentication service. 

c) It is recommended to use always use the optional ESP authentication service when using ESP encryption 
service. 

d) If only authentication services are needed, it is recommended to use ESP service with null encryption to 
accomplish this. 

e) It is recommended to choose underlying cryptographic algorithms depending on service provider and 
market requirements. (For North American applications 128 bit AES should be strongly considered). 

f) References [RFC 2401], [RFC 2402], [RFC 2403], [RFC 2404], [RFC 2405], [RFC 2406], [RFC 2407], 
[RFC 2408], [RFC 2409], [RFC 2410], [RFC 2411], [RFC 2412], [RFC 3602], [RFC 2451], [FIPS-197]. 
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SSL/TLS Security Services: 

Overview and Capabilities 

The Secure Sockets Layer (SSL) security protocol provides data encryption, server authentication, message integrity, 
and optional client authentication for a TCP/IP connection at the transport layer (layer 4). SSL is currently at revision 
3.0. Transport Layer Security (TLS) is the IETF standardized version of SSL which includes security enhancements 
over SSL including: 

• Required Diffie-Hellman and DSA digital signatures algorithm (DSA) support, with optional RSA 
support. 

• Use of stronger hashed message authentication algorithm (HMAC) instead of a non-standard SSL defined 
MAC algorithm. 

• Modified key generation algorithm which uses MD5 (Message Digest 5) and SHA-1 (Secure Hash 
Algorithm 1) with the HMAC. 

The SSL/TLS protocol runs above the Network Layer (Layer 4) and works with Transport Control Protocol (TCP) 
protocol only and cannot work with User Datagram Protocol (UDP). The application layer protocols that commonly 
run on top of SSL/TLS include, but are not limited to, Hypertext Transport Protocol (HTTP), the Lightweight Directory 
Access Protocol (LDAP), and the Internet Messaging Access Protocol. Higher application-level protocol can work 
above SSL/TLS without any regard for SSL/TLS; however the application level must be linked to SSL/TLS through the 
use of I/O callbacks. 

The SSL/TLS protocol provides three security functions for TCP traffic: data confidentiality, data integrity and 
authentication. 

The SSL/TLS security protocol architecture provides two layers which run over TCP: The SSL/TLS Upper Layer 
Protocols, and the SSL/TLS Record Protocol. 

The SSL/TLS Upper Layer Protocols includes the SSL/TLS Handshake Protocol, SSL/TLS Cipher Change Protocol, 
and the SSL/TLS Alert Protocol for notifications. SSL/TLS sessions are initially created by the SSL/TLS handshake 
protocol which provides: 

a) Negotiation of authentication and security mechanisms. 

b) Authentication of client and server. (Using the server and client public/private keys). 

c) Establishment of security keys. 

Once the SSL/TLS session is established, the SSL/TLS Record Protocol is used for bulk data transport services. The 
SSL/TLS Record Protocol provides: 

a) Data origin authentication based on the server keys. 

b) Data integrity. 

c) Confidentiality. 

Recommendations for use of SSL/TLS for Itf-N Security 

This section provides basic recommendation for the use of SSL/TLS for protection of network management traffic 
crossing the Itf-N interface, and is not intended to be exhaustive. 

a) Where SSL/TLS is required, either SSLv3 or TLS may be used . However, it is noted that TLS has 
enhanced security over SSL. 

b) SSL/TLS allows either unidirectional authentication where the server is authenticated to the client only, or 
bidirectional authentication where both client and server authenticate to each other. Unidirectional 
authentication is the usual method used in the public internet, however for network management 
applications bidirectional authentication is recommended to allow both parties to know they are 
communicating with the desired endpoint. 

c) References [RFC 2246], [RFC 3546], [SSL V3]. 
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SSH Security Services: 

Overview and Capabilities 

SSH is an Application Layer (Layer 7) security protocol commonly used to directly replace insecure protocols Telnet 
and File Transfer Protocol (FTP) protocols. Telnet and FTP are insecure protocols which transmit passwords and all 
other data in the clear. SSH can also be used to protect other protocols through the use of port forwarding, so it can be 
used as a general network security protocol. 

There are two versions of SSH: SSHvl and SSHv2. SSHvl was developed in 1998 and is now considered 
insecure/obsolete. 

Secure Shell 2 features are: 

• Full replacement for Telnet, Rlogin, Rsh, Rep, and FTP protocols to provide secure file transfer and file 
copying. 

• Automatic authentication of users, (no passwords sent in clear-text). 

• Bi-directional authentication (both the server and the client are authenticated). 

• Tunnelling of arbitrary TCP/IP-based applications through the use of port forwarding. 

• Encryption of data for data confidentiality. 

• Multiple authentication options including passwords, public key, and SecurelD authentication 

• Multiple ciphers suites available. 

The SSHv2 architecture is consists of three major components: 

• The Transport Layer Protocol [SSH-TRANS] provides server authentication, data confidentiality, and data 
integrity. It may optionally also provide compression. 

• The User Authentication Protocol [SSH-USERAUTH] authenticates the client-side user to the server. 

• The Connection Protocol [SSH-CONNECT] multiplexes the encrypted tunnel into several logical channels. 

The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are 
provided for setting up secure interactive shell sessions and for forwarding ("tunnelling") arbitrary TCP/IP ports and 
connections. 

Port number 22 has been registered with the I AN A as the standard port to use for SSHv2 applications. 

Recommendations for use of SSH for Itf-N Security 

This section provides basic recommendation for the use of SSH for protection of network management traffic crossing 
the Itf-N interface, and is not intended to be exhaustive. 

a) It is recommended to use SSHv2 where SSH protocol is required because of its widespread acceptance 
and enhanced security over SSHvl. 

b) SSHvl should be considered insecure/obsolete. 

c) Interoperating with an SSHvl protocol is not recommended and SSHvl connection attempts should be 
rejected. 

d) References [SSH- ARCH], SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT]. 

Conclusions/Recommendations 

IP Network Security protocols (IPsec, SSL/TLS or SSH) can be used to provide baseline infrastructure security between 
machines communicating across the Itf-N. It is recommended to use these IP Network security protocols to provide 
underlying security for the 3 GPP OA&M network, with the choice of protocols and cryptographic dependant on 
particular service provider and market requirements. 
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Annex B (informative): 

Firewalls for Network Security to Support Itf-N 

A firewall is a fundamental security building block that provides network isolation at boundaries between network 
segments or between different networks. A firewall performs isolation based on specific traffic filtering rules 
configured onto the firewall. Firewalls may be used in conjunction with other security mechanisms to provide an 
additional layer of security for the Itf-N interface. For the Itf-N interface, firewalls may be used to only allow traffic 
between the IRPManager and IRP Agent host machines to transit the firewall boundaries. The addition of firewalls at 
the Itf-N interface helps provide 'defence in depth' security whereby multiple security mechanisms are overlaid to 
achieve stronger security. 

A firewall examines both inbound and outbound traffic, and should be configured to deny all traffic unless specifically 
allowed by the firewall rules. A firewall may also provide logging of traffic and trigger alarms when unauthorized 
packets are detected. Firewalls can physically be provided for the Itf-N interface as separate appliances at the 
IRPManager and IRP Agent host machines or may be provided as software on the host machines themselves. Types of 
firewalls include static packet filtering, application layer, and state aware packet filtering firewalls. Any of the firewall 
types may be used to provide protection for the Itf-N interface, and the choice will depend on particular customer needs 
and preferences. 

Static packet filtering firewalls examine incoming and outgoing packets and apply a set of rules to determine whether 
packets will be allowed to transit the firewall or be dropped. This determination is typically based on the packet source 
and destination IP addresses, the protocol type, and the TCP source and destination ports. Depending on the packet and 
the criteria, the firewall will drop or forward the packet, and possibly create a log entry and/or raise an alarm. Some 
static packet filtering firewalls may also provide deeper inspection of packets, possibly up to the application layer. 

Application layer firewalls run applications on behalf of the machines in the network they are protecting, and are often 
called 'proxy' firewalls. When performing the applications, application layer firewalls will detect any anomalous 
activity and if found will not pass the data onto the machines they are protecting. Application layer firewalls must be 
enabled with all necessary application and must run these applications on behalf of all protected machines. Because of 
this, application layer firewalls have a high impact on network performance. 

State aware firewalls perform packet filtering functions similar to static packet filtering firewalls, and in addition 
maintain information about the state of traffic connections. The state information allows the firewall to make better 
decisions about whether to allow or deny particular traffic. For example, a state aware firewall may be configured to 
only allow traffic from machines on one side of the network to initiate communications. This is particularly useful 
where private networks are connected to public networks since typically only the machines on the private network are 
trusted to initiate data communications. 

When using firewalls as an additional security mechanism for the Itf-N interface, the firewalls should be configured to 
allow only communication between the IRPManager and the IRP Agent host machines. Any other traffic on the 
network attempting to access the IRPManager or IRP Agent host machines should be denied. This will isolate the 
IRPManager to IRP Agent network communications from other network traffic, thereby providing a layer of protection 
for these machines. 

Note that providing firewalls may have system engineering and product impacts, and some applications may have to be 
made firewall aware. Also note that firewalls will not protect against all security attacks such as an attacker spoofing 
legitimate IRPManager or IRP Agent packet information. 
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Annex C (informative): 
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